protect against link module creation

Hello,

is it possible disable links module creation for all users, except some ?

Regards
Pierre
PDU - Tue Jun 22 02:21:07 EDT 2010

Re: protect against link module creation
SystemAdmin - Wed Jun 23 15:33:46 EDT 2010

PDU,

We handle this issue by going through our projects formal modules and selecting module properties->linksets tab->checkbox-> only allow outgoing links as specified in the above list. By setting this feature on all modules it forces a controlled link module linkset setup of allowing for links as defined by a project requirements manager.

:) gsdguy

Re: protect against link module creation
llandale - Wed Jun 23 17:36:51 EDT 2010

If you don't want them creating ANY modules you can deny them "C" rights to the folders.

If you want them to yes create formal modules but not create link modules ... you could create the Doors links module in every folder and then delete it; that prevents those sorts of rougue links getting created. I think you are trying to stop them from creating rogue links themselvs, in which case you can control via the module properties Link Sets tab, as suggested in the other post.

  • Louie

Re: protect against link module creation
PDU - Thu Jun 24 02:20:06 EDT 2010

llandale - Wed Jun 23 17:36:51 EDT 2010
If you don't want them creating ANY modules you can deny them "C" rights to the folders.

If you want them to yes create formal modules but not create link modules ... you could create the Doors links module in every folder and then delete it; that prevents those sorts of rougue links getting created. I think you are trying to stop them from creating rogue links themselvs, in which case you can control via the module properties Link Sets tab, as suggested in the other post.

  • Louie

Thanks Greg and Louie, good ideas.

a little question more :

in our projects, we use not "DOORS links" module but links modules like "satisfies", "verifies", ...

Some project are a little bigs, so we use folder to organize.

What do you think is better :
  • use only one link module of every type, stored in one folder "links modules"
  • use several links module of each type,stored in formal modules folders.

It seems to me that the first solution is better, but we have in this case many link sets in one link module. As it is quite impossible see their source -> target in links module combobox selection, it can be difficult to manage.

Pierre

Re: protect against link module creation
SystemAdmin - Thu Jun 24 14:43:12 EDT 2010

PDU - Thu Jun 24 02:20:06 EDT 2010
Thanks Greg and Louie, good ideas.

a little question more :

in our projects, we use not "DOORS links" module but links modules like "satisfies", "verifies", ...

Some project are a little bigs, so we use folder to organize.

What do you think is better :

  • use only one link module of every type, stored in one folder "links modules"
  • use several links module of each type,stored in formal modules folders.

It seems to me that the first solution is better, but we have in this case many link sets in one link module. As it is quite impossible see their source -> target in links module combobox selection, it can be difficult to manage.

Pierre

Pierre,

Well, that is a really good question, and it just so happens that we may have stumbled into a system performance issue by creating a Link Module Folder under all of our Projects in DOORSv 9.1.0.3. On top of creating modules with links pointing out to another Template Project, which also contains link module folders that again point to several other projects that feed architecture and design elements all the way back to the new project module calling them. Finally, the icing on the cake, is Requirements Managers with DXL knowledge add some Layout DXL columns and even after setting these to Attribute DXL and wham oh!!! slow performing DOORS modules. Granted, they are HUGE modules a couple are upwards of 1600 pages when printed and also contain large numbers of OLE's and pictures....

So, my experience says while it is good to control linking, it can grow into a mess with too much control as well. I hope you find a happy medium that keeps the modules performing and not bogging down the users.
:)

gsdguy

Re: protect against link module creation
llandale - Fri Jun 25 15:30:16 EDT 2010

PDU - Thu Jun 24 02:20:06 EDT 2010
Thanks Greg and Louie, good ideas.

a little question more :

in our projects, we use not "DOORS links" module but links modules like "satisfies", "verifies", ...

Some project are a little bigs, so we use folder to organize.

What do you think is better :

  • use only one link module of every type, stored in one folder "links modules"
  • use several links module of each type,stored in formal modules folders.

It seems to me that the first solution is better, but we have in this case many link sets in one link module. As it is quite impossible see their source -> target in links module combobox selection, it can be difficult to manage.

Pierre

I read gsdguy's response but don't see the relationship between his many huge requiremrents modules with lots of OLE and attrDXL link displays; and whether you should put all the links in one link module or in many of the same name. Link modules are always pretty small, one small object per link set.

I'd be hard pressed to imagine a performance improvement by using more and diverse link-modules, each housing fewer link sets. Scattering Link Modules around is just asking for trouble, IMO.

Well, you are the only other person in the world that I've seen that suggests link module names reflecting the relationship between the objects. Yes, 'Links Satisfies' and 'Links Verifies' are superior names for the link modules housing the corresponding links. Yes, one would say "Requirement SubA_10 Satisfies Requirement Sys_02". You would also say the sys 'justifies' the sub, but that's relating the relationship in reverse order. That notion is better than 'Links Requirements' or 'Links Tests'.

As for your narrow link-set screen, the attached very old script resolves it.

  • Louie

Attachments

attachment_14480913_LinksetSelect.dxl

Re: protect against link module creation
SystemAdmin - Wed Mar 30 11:01:11 EDT 2011

llandale - Fri Jun 25 15:30:16 EDT 2010
I read gsdguy's response but don't see the relationship between his many huge requiremrents modules with lots of OLE and attrDXL link displays; and whether you should put all the links in one link module or in many of the same name. Link modules are always pretty small, one small object per link set.

I'd be hard pressed to imagine a performance improvement by using more and diverse link-modules, each housing fewer link sets. Scattering Link Modules around is just asking for trouble, IMO.

Well, you are the only other person in the world that I've seen that suggests link module names reflecting the relationship between the objects. Yes, 'Links Satisfies' and 'Links Verifies' are superior names for the link modules housing the corresponding links. Yes, one would say "Requirement SubA_10 Satisfies Requirement Sys_02". You would also say the sys 'justifies' the sub, but that's relating the relationship in reverse order. That notion is better than 'Links Requirements' or 'Links Tests'.

As for your narrow link-set screen, the attached very old script resolves it.

  • Louie

Louie,

Thread Necromancy, I know, but speaking from painful experience - that's not exactly true. It's actually much more accurate to think of each linkset as a small section in a sharable module. I can assure you that a link module with 3500 or so linksets will take a long time to open and will definitly impact performance - far worse if you have even a little latency on your network connection.

Re: protect against link module creation
llandale - Wed Mar 30 15:17:10 EDT 2011

SystemAdmin - Wed Mar 30 11:01:11 EDT 2011
Louie,

Thread Necromancy, I know, but speaking from painful experience - that's not exactly true. It's actually much more accurate to think of each linkset as a small section in a sharable module. I can assure you that a link module with 3500 or so linksets will take a long time to open and will definitly impact performance - far worse if you have even a little latency on your network connection.

3500 link sets?? lol That would be a single Sys spec with 5 Sub-System specs, each with 5 Segments, each with 5 Elements, each with 5 Components, each with 5.5 Unit specs; all linked upward. If your project is that huge then surely you will have other significant performance issues. Not used to those huge projects.

I suppose you could split the single link module into one for each SubSystem resulting in link modules with 700 linksets.

  • Louie

Re: protect against link module creation
SystemAdmin - Wed Mar 30 17:05:36 EDT 2011

llandale - Wed Mar 30 15:17:10 EDT 2011
3500 link sets?? lol That would be a single Sys spec with 5 Sub-System specs, each with 5 Segments, each with 5 Elements, each with 5 Components, each with 5.5 Unit specs; all linked upward. If your project is that huge then surely you will have other significant performance issues. Not used to those huge projects.

I suppose you could split the single link module into one for each SubSystem resulting in link modules with 700 linksets.

  • Louie

Yes, a very huge project. Users were linking to a very large number of small modules as part of an effort to link Simulink models to the requirements document. Our solution was a process to create a set of around 100 link modules at their "feature" level and create links through those for all modules under that branch of the project, then remove the old links (and linksets). We do seem to have a knack for finding the upper edge of the envelope in DOORS.

Re: protect against link module creation
PDU - Thu Mar 31 02:32:26 EDT 2011

llandale - Fri Jun 25 15:30:16 EDT 2010
I read gsdguy's response but don't see the relationship between his many huge requiremrents modules with lots of OLE and attrDXL link displays; and whether you should put all the links in one link module or in many of the same name. Link modules are always pretty small, one small object per link set.

I'd be hard pressed to imagine a performance improvement by using more and diverse link-modules, each housing fewer link sets. Scattering Link Modules around is just asking for trouble, IMO.

Well, you are the only other person in the world that I've seen that suggests link module names reflecting the relationship between the objects. Yes, 'Links Satisfies' and 'Links Verifies' are superior names for the link modules housing the corresponding links. Yes, one would say "Requirement SubA_10 Satisfies Requirement Sys_02". You would also say the sys 'justifies' the sub, but that's relating the relationship in reverse order. That notion is better than 'Links Requirements' or 'Links Tests'.

As for your narrow link-set screen, the attached very old script resolves it.

  • Louie

Hi Louie,

i look at your code (LinksetSelect.dxl), but a question :
you use function fDoScriptStartup(c_Version), in Lib-LibBasic.inc.

I don't have this library,
but without fDoScriptStartup(), script work.

What fDoScriptStartup() do ?

Pierre

Re: protect against link module creation
llandale - Thu Mar 31 12:58:48 EDT 2011

PDU - Thu Mar 31 02:32:26 EDT 2011
Hi Louie,

i look at your code (LinksetSelect.dxl), but a question :
you use function fDoScriptStartup(c_Version), in Lib-LibBasic.inc.

I don't have this library,
but without fDoScriptStartup(), script work.

What fDoScriptStartup() do ?

Pierre

Comment out the #include and that function.

fDoScriptStartup just checks to see if the script is 'allowed' to run on the current project, a silly notion the evil IT folks imposed on me that I've stopped supporting; and logs the fact that the script was run at all.

  • Louie